home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15968 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.8 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 8 Apr 1996 20:34:27 -0500
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4kcer3$mi4@solutions.solon.com>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU>
  9. Reply-To: seebs@solon.com
  10. NNTP-Posting-Host: solutions.solon.com
  11.  
  12. In article <4kbrt5$k3h@mulga.cs.mu.OZ.AU>,
  13. Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
  14. >It is clear that (a) such code is broken and (b) the fact that
  15. >it has undefined behaviour causes portability problems.
  16. >What you said and what Robert Dewar said are not contradictory.
  17.  
  18. Yes, they are.  There is no portability problem in the C language, or
  19. the behavior of read().  It is not a portability program for a mistake
  20. to behave randomly or differently on different machines.
  21.  
  22. >>I can't see how this is a "portability problem" any more than it's a
  23. >>portability problem that some systems will crash on
  24. >>    printf("%s", (char *) 0);
  25. >>... (SunOS won't, though.) 
  26.  
  27. >It is not *more* of a portability problem than `printf("%s", (char *) 0);',
  28. >but the undefined behaviour of read() and printf() both cause portability
  29. >problems.
  30.  
  31. No, they define the boundaries of a language; things beyond that boundary
  32. are *supposed* to be undefined.  Since no program in the C language ever
  33. runs into that behavior of a C implementation, it is not a portability
  34. problem.
  35.  
  36. >>Something which works only on some systems is
  37. >>not a portability problem *if there is no standard saying it works*.  Likewise
  38. >>    i = ++i;
  39. >>producing different results on different machines is not a "portability
  40. >>problem".
  41.  
  42. >Ha!  Obviously you have never tried porting any serious C programs.
  43.  
  44. Any program which does that is not a C program; it has left the bounds of
  45. defined behavior.
  46.  
  47. Further, that behavior is a flat out bug; it is never correct, and the
  48. portability problem lies in the program, not the language spec.  The
  49. program needs to be fixed.
  50.  
  51. >>(This applies to most of the C standard library, as well, of course.  The
  52. >>behavior you're used to, such as "void main(void)" or "fflush(stdin)" not
  53. >>working, is not a portability problem, it's broken code.)
  54.  
  55. >It's a portability problem AND it's broken code.
  56.  
  57. It's a portability problem if you write that broken code; well, don't do
  58. that then.
  59.  
  60. No point blaming the language for incompetent or foolish programmers.
  61.  
  62. -s
  63. -- 
  64. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  65. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  66. FUCK the communications decency act.  Goddamned government.  [literally.]
  67. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  68.